AWS Transit Gateway の共有スコープを変更した時の挙動を確認してみた
2025.01.14いわさです。
AWS Transit Gateway は組織内・外に共有することが出来ます。
そして共有先ではその Transit Gateway を参照してそれぞれアタッチメントを作成することができます。
Transit Gateway の共有は RAM (Resource Access Manager) のリソース共有を使って行います。
その RAM のリソース共有では様々なプリンシパルを指定して共有することができますが、共有スコープを再検討したくなった時に既存の Transit Gateway にどのような影響が出るのか気になりました。
今回は次のような組織で検証してみました。
Account1 で Transit Gateway を作成＆組織内に共有し、Account2 と Account3 で使用します。
その後共有先を hogeOU-A のみに変更してみます。
そうした時に Transit Gateway がどのような挙動になるのか確認してみたいと思います。
組織 ID を指定して共有
まずは組織 ID を指定して共有します。
RAM のリソース共有はこんな感じです。
そして Transit Gateway で共有設定します。
これで Account2 と Account3 から Account1 を使った Transit Gateway アタッチメントが作成出来ました。
組織ではなく OU を指定するように共有変更してみる
さてここで Transit Gateway が関連づいているリソース共有の設定を変更し、組織全体の指定ではなく特定 OU を指定して共有する形にスコープダウンしてみます。
まず、リソース共有でリソースが共有されていたとしてもスコープ変更が出来なくなるということはありませんでした。スコープダウンできました。
ここで現在のスコープ内で使用中のため変更できないという可能性を考えていたのですがそうはならないようです。
先ほどの組織構造でいうhogeOU-Aを指定しました。これでhogeOU-Bに所属する Account3 には共有がされなくなるはずです。
Account3 の VPC コンソールを確認してみると、共有されていた Transit Gateway が参照できなくなっていることを確認しました。
続いてアタッチメントですが、こちらは存在していました。
また、ステータスも変わっておらず引き続き利用可能な状態です。
さらに Account1 からルートテーブルに指定も可能な状態です。
Transit Gateway が参照できなくなったタイミングでアタッチメントが削除されてしまう可能性を考えていたのですが、そうはならないようです。
実はこのあたりに類似した仕様が公式ドキュメントにも記載されています。
トランジットゲートウェイの共有解除
共有所有者がトランジットゲートウェイの共有を解除する場合、次のルールが適用されます。
- トランジットゲートウェイアタッチメントは、機能し続けます。
- 共有アカウントでトランジットゲートウェイを示すことはできません。
- トランジットゲートウェイの所有者および共有所有者は、トランジットゲートウェイアタッチメントを削除できます。
トランジットゲートウェイが別の AWS アカウントと共有されていない場合、またはトランジットゲートウェイが共有されている AWS アカウントが組織から削除された場合、トランジットゲートウェイ自体は影響を受けません。
なるほど、どうやら作成済みの Transit Gateway アタッチメントは共有状況の変化によって特に影響を受けることなく引き続き機能し続けることができるようです。
ためしに RAM の共有プリンシパル変更ではなく、Transit Gateway の共有機能からリソース共有との関連付け自体を停止してみたのですが、その際にダイアログにも次のように記載がされていました。
共有解除後は新規アタッチメント作成に失敗する
一点注意点としては共有されていた Transit Gateway の参照ができなくなるので、それを使ったアタッチメントの作成はできなくなります。
マネジメントコンソールであれば次のように選択ができなくなりました。
また、API 経由で実行する場合も次のようにエラーとなりました。
[cloudshell-user@ip-10-130-48-51 ~]$ aws ec2 create-transit-gateway-vpc-attachment --cli-input-json file://hoge.json
An error occurred (InvalidTransitGatewayID.NotFound) when calling the CreateTransitGatewayVpcAttachment operation: Transit Gateway tgw-020bd66db2acb761a was deleted or does not exist.
なお、RAM でリソース共有のスコープに該当 OU を追加してあげることで引き続き API からでもコンソールからでもアタッチメントが再び作成できるようになります。
[cloudshell-user@ip-10-130-48-51 ~]$ aws ec2 create-transit-gateway-vpc-attachment --cli-input-json file://hoge.json
{
"TransitGatewayVpcAttachment": {
"TransitGatewayAttachmentId": "tgw-attach-063eeeea73ca4512c",
"TransitGatewayId": "tgw-020bd66db2acb761a",
"VpcId": "vpc-033665ac2e3aeda27",
"VpcOwnerId": "123456789012",
"State": "pending",
"SubnetIds": [
"subnet-0f9b3004ec431c772"
],
"CreationTime": "2025-01-13T21:04:40+00:00",
"Options": {
"DnsSupport": "enable",
"SecurityGroupReferencingSupport": "enable",
"Ipv6Support": "disable",
"ApplianceModeSupport": "disable"
},
"Tags": [
{
"Key": "Name",
"Value": "hoge0112tgwatt"
}
]
}
}
例えば AWS Proton や AWS Service Catalog などのように組織内で繰り返し再利用されるネットワーク構成のテンプレートがある場合は注意したほうが良さそうです。作成に失敗するようになるかも。
さいごに
本日は AWS Transit Gateway の共有スコープを変更した時の挙動を確認してみました。
スコープ変更する際に Transit Gateway の利用が停止してしまうリスクがあるとちょっとこれは変更しづらいぞ？と思っていたのですが、既存アタッチメントについては引き続き利用出来るということで安心しました。
![[レポート] セキュリティとネットワークの GameDay に参加してきました #GHJ303 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
![[登壇レポート] VPC間の接続方法を整理してみた #自治体クラウド勉強会](https://images.ctfassets.net/ct0aopd36mqt/6WDF8DnUY0lRO6CiIHDszj/395fdc3b14a82a82ca9f794ee9494118/amazon-vpc.webp)
